1. Field of the Invention
The present invention relates generally to a mobile communication system, and in particular, to an efficient retransmission apparatus and method for high-speed data processing.
2. Description of the Related Art
A Universal Mobile Telecommunication Service (UMTS) system is a 3rd Generation Partnership Project (3GPP) asynchronous mobile communication system that is based on Global System for Mobile Communications (GSM) and General Packet Radio Services (GPRS), both of which are European mobile communication systems, and uses Wideband Code Division Multiple Access (WCDMA).
In the 3GPP, now in charge of UMTS standardization, Long Term Evolution (LTE) is under discussion as a next generation mobile communication system of the UMTS system. LTE is technology for realizing high-speed packet based communication at about 100 Mbps. Several LTE schemes are now under discussion. For example, LTE schemes include a scheme of reducing the number of nodes located in a communication path by simplifying architecture of networks, and another scheme of maximally approximating wireless protocols to wireless channels.
An LTE system uses Hybrid Automatic Retransmission reQuest (HARQ) to increase transmission efficiency of high-speed packets, and because the LTE system cannot meet various Quality-of-Service (QoS) conditions only with HARQ, outer Automatic Retransmission reQuest (ARQ) can be performed in an upper layer.
HARQ, as used herein, refers to a technique of soft-combining previously received data with retransmitted data without discarding the previously received data, thereby increasing a reception success rate. More specifically, a HARQ receiving entity determines presence/absence of an error in a received packet and then sends an Acknowledged (HARQ ACK) signal or a Non-Acknowledged (HARQ NACK) signal to a transmitting entity according to the presence/absence of an error. Therefore, the transmitting entity performs retransmission of the corresponding HARQ packet or transmission of a new HARQ packet according to the HARQ ACK/NACK signal. That is, the HARQ technique is characterized by soft-combining a retransmitted packet with a previously received packet, thereby reducing an error occurrence probability.
However, ARQ refers to a technique of checking sequence numbers of received packets and issuing a retransmission request for a missing packet according to the check result, without performing a soft-combining operation between a previously received packet and its retransmitted packets. It is considered that because ARQ and HARQ both serve to recover errored packets, there is no need to operate both of them together. However, because it is hard to obtain a sufficiently low packet error ratio only with HARQ, both ARQ and HARQ should be simultaneously performed in most packet services, for the following reason. That is, as the HARQ ACK/NACK signal is a 1-bit signal, if a HARQ NACK signal is misconceived as a HARQ ACK signal (HARQ NACK/ACK error), the corresponding packet can be completely lost in a HARQ level. As a result, reliability of the HARQ ACK/NACK signal acts as an important factor in determining a packet error ratio in the HARQ level. Therefore, in a mobile communication system employing both HARQ and ARQ, an ARQ transmitting entity can perform fast retransmission using HARQ transmission information.
FIGS. 1A and 1B show a structure of a general radio protocol and an associated packet structure, respectively. The radio protocol of FIG. 1A is composed of ARQ layers 120 and 125, a Medium Access Control (MAC) layer 130, and a physical layer 140. The ARQ layers 120 and 125 can be configured independently for every service, and they satisfy the QoS through an ARQ operation.
An upper layer #1 110 and an upper layer #2 115 are protocol stacks, each of which is configured independently for each individual service. For example, an upper layer can be a protocol stack of an Adaptive Multi Rate (AMR) coder/decoder (codec)—Real Time Protocol (RTP)—User Diagram Protocol (UTP)—Internet Protocol (IP) (codec/RTP/UDP/IP) or a File Transfer Protocol (FTP)—Transmission Control Protocol (TCP)—IP (FTP/TCP/IP). The MAC layer 130 is connected to a plurality of ARQ layers 120 and 125, and multiplexes a plurality of ARQ packets into one HARQ packet. Further, the MAC layer 130 performs a HARQ operation on the multiplexed HARQ packet. The physical layer 140 performs an operation of transmitting and receiving the HARQ packet over a wireless channel. An ARQ packet is a packet reconfigured by allocating sequence numbers so an ARQ operation can be performed on the data delivered from the upper layer. The HARQ packet means a unit packet which is actually transmitted and received on a wireless channel through a HARQ operation.
The ARQ packet of FIG. 1B includes an ARQ packet header 161 composed of a Sequence Number (SN) 163, size information 164 and framing information 165, and a payload 162 to which actual data delivered from the upper layers 110 and 115 are allocated.
For example, if an IP packet 150 has been delivered from the upper layers 110 and 115 to the ARQ layers 120 and 125 of FIG. 1A, the ARQ layers 120 and 125 can transmit the IP packet 150 completely or partially according to wireless channel situation or scheduling situation. A process of reconfiguring an IP packet 150 delivered from the upper layers 110 and 115 in an appropriate size is herein called ‘framing’, and the framing information 165 is the information with which a receiving entity can restore a packet reconfigured in an appropriate size to the original upper layer packet (IP packet). The sequence number 163 is a sequence number sequentially assigned to the ARQ packet 160, and the size information 164 is the information indicating a size of the ARQ packet 160. The ARQ layers 120 and 125 perform an ARQ operation of storing or assembling ARQ packets using the sequence number 163.
A HARQ packet 170 is composed of a multiplexing header 171 and a payload. The multiplexing header 171 includes multiplexing information of the ARQ packet 160. For example, an identifier of a corresponding one of the ARQ layers 120 and 125 can be the multiplexing information. The payload is composed of more than one multiplexed ARQ packet 160. The radio protocol structure shown in FIG. 1A and the packet structure shown in FIG. 1B can be commonly applied to a base station and a terminal.
FIG. 2 shows a general HARQ operation in HARQ architecture between a transmitting entity and a receiving entity. In a general uplink packet service, a terminal serves as the transmitting entity and a base station serves as the receiving entity. On the contrary, in a general downlink packet service, a terminal serves as the receiving entity, and a base station serves as the transmitting entity. In the following description, therefore, the transmitting entity and the receiving entity should not be limited to one of the terminal and the base station.
In FIG. 2, because various types of services can be provided to one terminal, the transmitting entity includes a plurality of upper layers 280 and a multiplexing block 275, and the receiving entity includes a plurality of upper layers 205 and a demultiplexing block 210. The upper layers 205 and 280 can be regarded as, for example, a set of services using the same QoS, and for convenience, the flow that has occurred in one upper layer will be referred to below as a ‘QoS flow’.
The multiplexing (MUX) block 275 serves to insert multiplexing information into the data generated by the several upper layers 280 and to deliver the resulting data to a HARQ block 272. On the contrary, the demultiplexing (DEMUX) block 210 performs an operation of delivering multiplexing information of the data provided from a HARQ block 212 to the appropriate upper layers 205.
The HARQ blocks 212 and 272, devices for performing a HARQ operation, are each made up of several HARQ processors. A HARQ processor is a unit device in charge of transmission/reception of a HARQ packet. A transmitting HARQ processor (i.e. a HARQ processor in the transmitting entity) takes charge of transmission and retransmission of user packets, and a receiving HARQ processor (i.e. HARQ processor in the receiving entity) takes charge of reception of a HARQ packet and transmission of a HARQ Acknowledgement (HARQ ACK)/HARQ Negative Acknowledgement (HARQ NACK) signal.
The HARQ blocks 212 and 272 exist in pairs in the transmitting entity and the receiving entity, and each of the HARQ blocks 212 and 272 includes a plurality of HARQ processors, thereby enabling continual transmission/reception. An operation of the HARQ processor includes transmitting a HARQ packet, receiving HARQ ACK/NACK information in response thereto, and performing retransmission on the HARQ packet according to the HARQ ACK/NACK information. For example, therefore, if there is only one HARQ processor, the transmitting entity, after transmitting user data, cannot transmit another packet until it receives HARQ ACK/NACK information for the user data. However, when several HARQ processors are provided, while one processor waits for a HARQ ACK/NACK, other processors can transmit data. This makes continuous transmission/reception possible.
A basic operation of the HARQ processor is as follows.
A transmitting HARQ processor, any one of HARQ P1 250, HARQ P2 260, HARQ P3 265 and HARQ P4 270, channel-codes and transmits data received from the multiplexing block 275, and stores the channel-coded data in a buffer (not shown) for later retransmission. The transmitting HARQ processor discards (flushes) the data stored in the buffer upon receipt of ACK information for the data, and performs retransmission on the data upon receipt of NACK information for the data.
On the contrary, a receiving HARQ processor, any one of HARQ P1 215, HARQ P2 220, HARQ P3 225 and HARQ P4 230, channel-decodes the data received over a physical channel, and determines presence/absence of an error through a Cyclic Redundancy Check (CRC) operation of checking whether there is any error detected from the data. In presence of an error, the receiving HARQ processor stores the data in a buffer (not shown), and sends a HARQ NACK signal. Thereafter, if retransmitted data for the data is received, the receiving HARQ processor soft-combines the retransmitted data with the data previously stored in the buffer, and then determines again presence/absence of an error in the soft-combined data. If it is determined that there is still an error, the receiving HARQ processor sends a HARQ NACK signal and repeats the above process. However, if it is determined that there is no error, the receiving HARQ processor sends a HARQ ACK signal and delivers user data to the demultiplexing block 210.
The HARQ operation can increase its reliability by retransmitting an errored HARQ packet and performing soft-combining thereon in this manner. However, it is inefficient to achieve a very low Block Error Rate (LBER) only with the HARQ operation.
This is caused by the following two reasons.
1. If there is an error in a HARQ ACK/NACK signal, the HARQ processor fails to detect the error.
2. Because HARQ transmission/retransmission is performed within a relatively short time, a HARQ processor fails to acquire time diversity gain. For example, if a terminal falls in deep fading for several tens of milliseconds, the terminal can hardly successfully transmit a HARQ packet through HARQ retransmission. In order to make up for the limit of the HARQ operation, there is a need to perform an ARQ operation. With reference to FIG. 3, a description will now be made of an operation of performing HARQ with use of ARQ.
FIG. 3 illustrates possible problems occurring when HARQ and ARQ operate independently according to the prior art. In FIG. 3, an ARQ operation is performed by transmitting ARQ layers 361, 362 and 363 (i.e. ARQ layers in the transmitting entity) and receiving ARQ layers 311, 312 and 313 (i.e. ARQ layers in the receiving entity). The transmitting ARQ layers 361, 362 and 363 each store an ARQ packet in a retransmission buffer for its possible retransmission, even after transmitting an upper layer packet delivered from an upper layer.
The transmitting ARQ layers 361, 362 and 363 form an ARQ assembly clock and each configure as many ARQ packets as the amount of data that it will transmit for a transmission period. The transmitting ARQ layer can reach the amount of desired transmission data by generating several ARQ packets, or can generate one ARQ packet corresponding to the amount of desired transmission data. If a size of a desired ARQ packet is not identical to a size of the upper layer packet, the transmitting ARQ layer can deliver only a part of the ARQ layer by dividing the upper layer packet, or can deliver a plurality of upper layer packets. The transmitting ARQ layer configures the ARQ packet by inserting sequence number information, size information, and framing information into an upper layer packet. The transmitting ARQ layer stores the ARQ packet in a retransmission buffer for later retransmission after storing it to a lower layer. The lower layer may include a MAC layer, a HARQ layer 370, and a physical layer. The HARQ layer 370 multiplexes the received ARQ packets into a HARQ packet, and then transmits the HARQ packet in step 380 to the receiving entity over a physical channel.
The receiving ARQ layers 311, 312 and 313 are each composed of an assembly block, a reception buffer, and a retransmission management block. The physical layer receives a HARQ packet over a physical channel, and a MAC/HARQ layer 320 demultiplexes the received HARQ packet to restore ARQ packets, and delivers the ARQ packets to the corresponding receiving ARQ layers 311, 312 and 313. The reception buffer stores the ARQ packets received from the HARQ layer 320 according to their sequence numbers, and delivers assemblable ARQ packets to the assembly block. The ARQ retransmission management block checks sequence numbers of the ARQ packets stored in the reception buffer, and sends ARQ ACK signals for the normally received ARQ packets and ARQ NACK signals for the reception-failed ARQ packets to the transmitting ARQ assembly block of ARQ layers 361, 362 and 363 in steps 341, 342, 343. The ARQ assembly block reconfigures (reassembles) the original upper layer packet with the ARQ packets referring to framing headers of the ARQ packets delivered from the reception buffer, and then delivers the reconfigured upper layer packet to the upper layer.
Upon receiving the response signals (ACK/NACK signals) for the ARQ packets previously transmitted to the receiving ARQ layers 311, 312 and 313, the transmitting ARQ layers 361, 362 and 363 each discard the corresponding ARQ packet from the ARQ retransmission buffer in response to the ACK signal, and schedule retransmission of the corresponding ARQ packet in response to the NACK signal.
As described above, ARQ is performed on an ARQ packet by ARQ packet basis. The transmitting ARQ layers 361, 362 and 363 attach sequence numbers to ARQ packets before transmission, and the receiving ARQ layers 311, 312 and 313 check the sequence numbers of the received ARQ packets to determine whether there is any missing (reception-failed) ARQ packet. For example, if the receiving ARQ layers have normally received an ARQ packet with a sequence number #X and an ARQ packet with a sequence number #(X+2), but have failed to receive an ARQ packet with a sequence number #(X+1), the receiving ARQ layers send a request for retransmission of the ARQ packet with a sequence number #(X+1) to the transmitting ARQ layers. That is, the receiving ARQ layers send a NACK signal to the transmitting ARQ layers in response to the ARQ packet with a sequence number #(X+1), to issue a request for retransmission of the ARQ packet with a sequence number #(X+1).
A description will now be made of a HARQ operation performed independently of the ARQ operation in FIG. 3.
After transmitting a HARQ packet obtained by multiplexing a plurality of ARQ packets, if the transmitting HARQ layer 370 receives a HARQ NACK from the receiving HARQ layer 320, the transmitting HARQ layer 370 retransmits the HARQ packet. That is, upon failure to receive a HARQ ACK, the transmitting HARQ layer 370 repeats this operation as many times as a maximum number of retransmissions. If the transmitting HARQ layer 370 has failed to receive the HARQ ACK even after it has repeated the operation as many times as the maximum number of retransmissions, i.e. if the maximum retransmission limit occurs, the receiving HARQ layer 320 sends a HARQ ACK/NACK in step 382, perceiving the occurrence of the maximum retransmission limit, and the transmitting HARQ layer 370, after receiving the HARQ ACK/NACK, sends a request for retransmission of the corresponding packet to the ARQ layers 361, 362 and 363.
In this case, the transmitting HARQ layer 370 cannot perform retransmission until it receives an ARQ NACK. Therefore, when the HARQ maximum retransmission limit occurs, the transmitting HARQ layer 370 can hardly perform fast retransmission. Also, the receiving ARQ layers 311, 312 and 313 should send NACKs for all reception-failed ARQ packets, causing an increase in the wireless load and the ARQ NACK processing load. In addition, because the receiving ARQ layers 311, 312 and 313 use several types of ARQ ACK/NACKs, packet processing is complex in the ARQ layers. Further, while the HARQ layer 370 attempts retransmission, if the receiving ARQ layer sends a NACK, determining that an arbitrary ARQ packet is missing, then the HARQ layer 370 may perform repeated retransmission on the same ARQ packet. This defect causes deterioration in packet transmission/reception performance.
To solve the problem of FIG. 3, conventional technology proposes a method for efficiently operating a HARQ layer and an ARQ layer, which operate independently, as shown in FIG. 4. That is, a receiving HARQ layer 420 uses a method of providing information on success/failure in packet transmission to transmitting ARQ layers 461, 462 and 463.
Referring to FIG. 4, a transmitting HARQ layer 470 sends transmission failure information (Local NACK) and transmission success information (Local ACK) to the transmitting ARQ layers 461, 462 and 463 so they may determine whether there is a need for retransmission of the corresponding packet. The receiving ARQ layers 411, 412 and 413 do not use the ARQ ACK/NACK for a missing packet.
In other words, in FIG. 4, in order to solve problems of a load caused by an ARQ operation and possible occurrence of a repeated retransmission request due to the use of the HARQ layer, a transmitting entity and a receiving entity do not perform ARQ. Instead, the receiving HARQ layer 420 performs demultiplexing on the HARQ packet transmitted via the transmitting HARQ layer 470, and the corresponding ARQ layers 411, 412 and 413 perform error check on the received demultiplexed ARQ packets, and deliver the results to the receiving HARQ layer 420.
Therefore, the receiving HARQ layer 420 sends a HARQ NACK signal to the transmitting HARQ layer 470, causing the HARQ layer 470 to perform retransmission.
In addition, the receiving HARQ layer 420 performs HARQ NACK/ACK error detection, and if a HARQ NACK is recognized as a HARQ ACK due to its change, i.e. if it is determined that a HARQ NACK/ACK error has occurred, the receiving HARQ layer 420 sends a NACK/ACK error indicator to the transmitting HARQ layer 470. A process of sending a NACK/ACK error indicator will be described in FIG. 5.
Finally, upon receipt of a Local ACK from the transmitting HARQ layer 470, the transmitting ARQ layers 461, 462 and 463 can remove the corresponding ARQ packet from a retransmission buffer. However, upon receipt of a Local NACK reported from the transmitting HARQ layer 470, the transmitting ARQ layers 461, 462 and 463 prepare for retransmission of the corresponding ARQ packet.
FIG. 5 shows an operation of detecting a NACK/ACK error according to the prior art. In FIG. 5, a transmitting HARQ layer (or HARQ transmitting entity) 555 transmits, in step 510, a HARQ packet to a receiving HARQ layer (or HARQ receiving entity) 505 over a physical channel. The receiving HARQ layer 505 performs error detection on the received HARQ packet. If there is an error in the received packet, the receiving HARQ layer 505 sends, in step 520, a HARQ NACK to the transmitting HARQ layer 555. Even though the receiving HARQ layer 505 has sent the HARQ NACK, if the transmitting HARQ layer 555 transmits a new HARQ packet in step 530 instead of retransmitting the HARQ packet to the receiving HARQ layer 505, the receiving HARQ layer 505 considers, in step 540, that a NACK/ACK error has occurred for the previously sent NACK response signal. That is, when the NACK signal for the HARQ packet transmitted in step 510 experiences an error while it is transmitted over a wireless channel in step 520, the transmitting HARQ layer 555 recognizes the NACK signal as an ACK signal, and thus transmits a new HARQ packet in response to the ACK signal in step 530.
Upon detecting the NACK/ACK error in this way, the receiving HARQ layer 505 sends a NACK/ACK error indicator to the transmitting HARQ layer 555 in step 550.
FIG. 6 illustrates possible problems occurring when the conventional HARQ and ARQ operate as shown in FIGS. 3 to 5.
In FIG. 6, ‘case 1’ corresponds to a case in which a receiving ARQ layer 601 normally receives an ARQ packet 610 transmitted by a transmitting ARQ layer 608 in step 616. The ARQ packet 610 is delivered to the receiving ARQ layer 601, passing through a transmitting HARQ layer 605 and a receiving HARQ layer 603 in steps 612 and 616, respectivley.
After receiving a HARQ ACK indicating normal receipt of the transmitted packet from the receiving HARQ layer 603 in step 614, the transmitting HARQ layer 605 starts a timer, in step 630, with which the transmitting HARQ layer 605 waits for an NACK/ACK error indicator. Thereafter, if the timer expires in step 632, the transmitting HARQ layer 605 reports a Local ACK to the transmitting ARQ layer 608 in step 618.
Upon receipt of the Local ACK reported from the transmitting HARQ layer 605, the transmitting ARQ layer 608 can finally remove the packet from a retransmission buffer in step 620, determining that the corresponding ARQ packet has been normally received at the receiving ARQ layer 601.
‘case 2’ corresponds to a case in which packet transmission is failed, even though the transmitting HARQ layer 605 has attempted retransmission as many times as the maximum number of retransmissions in steps 640 to 650. In this case, the transmitting HARQ layer 605 reports a Local NACK to the transmitting ARQ layer 608 in step 652, and the transmitting ARQ layer 608 prepares to retransmit the corresponding ARQ packet in step 654.
‘case 3’ corresponds to a case in which a HARQ NACK is misconceived as a HARQ ACK in step 674. After receiving a HARQ ACK, the transmitting HARQ layer 605 starts a timer in step 676 with which the HARQ layer 605 waits for a NACK/ACK error indicator. Upon receipt of a NACK/ACK error indicator from the receiving HARQ layer 603 in step 678 before expiration of the timer, the transmitting HARQ layer 605 reports a Local NACK to the transmitting ARQ layer 608 in step 680. Upon receipt of the Local NACK, the transmitting ARQ layer 608 prepares to retransmit the corresponding ARQ packet.
This method has the following problems, although it has an advantage of not using the ARQ ACK/NACK.
1. The HARQ layer is complex in operation because it should determine presence/absence of a NACK/ACK error and perform the corresponding process.
2. Even though the receiving HARQ layer 603 has sent a HARQ NACK, if a new HARQ packet is received, the receiving HARQ layer 603 determines that there is a NACK/ACK error. However, if the transmission is failed, even though the transmitting HARQ layer 605 has sent the corresponding packet as many times as the maximum number of retransmissions, the transmitting HARQ layer 605 transmits a new HARQ packet. This case can hardly be distinguished from the case where the NACK/ACK error has occurred.
3. Because the transmitting HARQ layer 605 should always report a Local ACK for the successfully transmitted packet, the transmitting HARQ layer 605 and the transmitting ARQ layer 608 both increase in processing overhead.
4. There is no detailed scheme for sending the NACK/ACK error indicator.
5. There is no scheme for coping with the case where the NACK/ACK error indicator is missing or changes. In the case where the NACK/ACK error indicator is missing, if the timer expires while the transmitting HARQ layer 605 waits for the NACK/ACK error indicator, the transmitting HARQ layer 605 generates a Local ACK, determining that there is no NACK/ACK error.
Detailed schemes for solving the foregoing problems have not yet been proposed in current mobile communication systems. Therefore, a need exists for an efficient packet retransmission method for transmitting high-speed data taking the foregoing problems into account.